Context

This card to remove the 'apply_2' deadline was created in July last year during the continuous application work. Now that we have started doing the end of cycle work again this year, it is apparent that this apply_1 and apply_2 logic creates confusion and should be removed before we move forward.

Changes proposed in this pull request

Broadly, the PR just:

• adds an apply_deadline to the cycle definitions
• replaces methods in the CycleTimeable service to remove the distinction between the two deadlines.

For backward compatibility, I have retained the apply_1 and apply_2 deadlines on those cycles where it was relevant.

What IS NOT in this PR (tickets to be written for the following):

• Completely remove the apply_again concept (apply_again is defined throughout the code base as apply_2 applications with submitted statuses. There are no apply_2 applications now, so this is irrelevant, but too big for this pr
• Remove the phase column from the application. This is 'apply_1' for all applications so just extra noise that we should remove. But too big for this ticket.
• Change the way we store / maintain cycle deadlines. We need to decide how far back we want to keep this data and if we are keeping ad infinitum, we should start storing it in the database rather just a constant in the codebase.

Guidance to review

I've got the test suite passing and I've done lots of manual testing locally. Would appreciate other people to do lots of clicking and see if I've broken anything.

It's a big PR, so best to review commit by commit.

Link to Trello card

https://trello.com/c/FPph5syu

Things to check

• If the code removes any existing feature flags, a data migration has also been added to delete the entry from the database
• This code does not rely on migrations in the same Pull Request
• If this code includes a migration adding or changing columns, it also backfills existing records for consistency
• If this code adds a column to the DB, decide whether it needs to be in analytics yml file or analytics blocklist
• API release notes have been updated if necessary
• If it adds a significant user-facing change, is it documented in the CHANGELOG?
• Required environment variables have been updated added to the Azure KeyVault